FMEA和控制计划之间，容易出现一种情况，就是风险分析做得很细，到了现场控制那一层，却没有完整地接住，在汽车零部件、电子装配、机加工还有注塑这类项目里面，这个问题尤其常见，FMEA评审的时候，失效的模式、失效带来的后果、背后的原因、预防的措施还有探测的办法，都列了不少，可等到了控制计划这个阶段，现场真正需要去控制的那些尺寸、参数、工装的状态、检测的频次，反而没有完整地衔接上，表面上看，两个文件好像都做完了，可真要仔细一查，就会发现，风险分析还留在当初开会的表格里，控制计划也只是挂在生产现场的表格里，中间那一次认真的传递，被漏掉了。

在功能安全、质量策划、过程审核和设计评审这些工作里面，我们常常会碰到两个连在一起的问题，一个是FMEA的失效影响到底要展开到多细才合适，另一个是，如果对失效链路的梳理做得太深，又会带来什么样的麻烦，FMEA做得太粗，评审的时候就会被认为没有把风险给讲透，后面的控制办法也容易落空；可要是做得太细，又可能把整个团队拖进大量价值不高的推演当中，表格越写越厚，而真正需要优先去处理的高风险项，反而被淹没了，更稳当的一种做法，是把失效影响展开到“能判断风险、能定义控制、能分配责任”这个程度，而不是把每一个细枝末节都拆解成一条独立的失效链。

在质量评审、设计变更还有过程审核这些场景里面，有两个问题常常被连在一起看，一个是FMEA里的高风险项为什么迟迟关不掉，另一个是FMEA的措施优先级，一般是按照什么样的逻辑来排的，单看表格的时候，好像只是有几行风险没有关闭，但是到了现场一查，后面很可能连着责任人没有说清楚、措施写得太空、验证的证据不够、风险的分数也没有重新去确认这一类的问题，FMEA并不是把措施填进表格就算把事情做完了，一个高风险项到底能不能被关掉，要看它背后那个失效的原因，有没有被真正地处理掉，而措施优先级的排法，也要按照风险带来的后果和实际可执行的条件来定，不能只是看谁催得比较急。

FMEA边界图总是画不清问题出在哪，FMEA结构分析漏项一般出现在什么环节，这两个问题在实际评审里经常连在一起。边界图画不清，后面的结构树、功能分析和失效分析都会跟着发散，评审时看似是在争论某个零件要不要放进去，其实前面系统范围、接口关系和层级拆分已经含糊了。FMEA结构分析要先把对象讲明白，再把上下游关系、内部组成和外部接口补完整，否则表格写得再满，也容易出现漏项。

在研发评审、质量策划以及客户审核这些场合里，大家经常会问到这样一个问题：FMEA的七步法是不是每一个项目都需要完整地做下去，还有，当我们对七步法做裁剪的时候，通常会把哪些步骤保留下来。七步法本身提供的是一套完整的分析路径，但不同的项目，规模不一样，产品的成熟度不一样，变更的范围不一样，客户提出的要求也不一样，如果直接就把整套流程照搬过来，有时候会让简单的问题变得很重；反过来，要是裁剪得太随便了，到评审的时候又很难说清楚为什么有些内容没有去做。所以，真正需要我们搞明白的是，哪些步骤属于风险分析里面的骨架，哪些内容可以适当地简化，又有哪些证据是一定要留下来的。

搭FMEA系统时，最容易走偏的地方，不是界面长什么样，而是把结构树、表单字段、行动项和审批流程拆成了几块互不相连的东西。公开资料里已经把一条更稳的路线写得很清楚，APIS IQ-FMEA这类工具本身就把Structure Tree、Function Nets、FMEA Form、Action Tracking、Terminology management、Audit Trail、Planning and Preparation与Results documentation放在同一套体系里；而Relyence也明确把Action Workflow和Approvals作为推荐措施控制的流程机制，并强调审批不能脱离工作流单独存在。也就是说，FMEA系统如果只是一张表，后面一定会越用越散。

做FMEA的时候，很多团队前面最顺手的动作，就是先给严重度、发生度、探测度打分，再把RPN一乘，谁大先看谁。这个方法不是不能用，但真到项目现场，单靠一个乘积数字往往不够。因为有些问题严重度很高，只是发生概率暂时不高，RPN看起来不算特别扎眼，可一旦出了事，后果并不轻。还有些问题RPN数值不小，但更多是探测度拉高了分数，未必就是当前最急着处理的项。所以RPN能用，但不能被用死。它更像是一把筛子，先帮你把问题排个队，后面真正怎么处置，还得回到失效后果、现场经验和项目节奏上来看。

做FMEA时，发生度最容易被打分打偏。真正常见的问题，不是团队不会填1到10，而是把“故障后果严重不严重”和“原因出现得频不频繁”混到了一起。公开资料里对这件事说得很清楚，FMEA风险排序本来就是围绕严重度、发生度和探测度三维展开，而发生度评的是发生频次，不是影响大小；在DFMEA和PFMEA的公开评分表说明里，发生度也都直接写成了“Cause的发生”以及“基于已知数据或缺少数据的估计”。

做FMEA时，最容易写虚的一栏就是“影响”。很多表格里把影响写成一句笼统的“功能异常”就往下走，结果后面严重度打不准，措施也落不实。FMEA的基本逻辑并不复杂，先找失效模式，再看这个失效会带来什么后果，然后再评后果有多严重。VDA的公开资料把FMEA定义为一种结构化、系统化的方法，用来尽早识别失效及其风险，并通过措施把风险压下去；而APIS的FMEA表单说明也明确把effects放在失效模式之后、严重度评价之前。

做FMEA时，最容易出偏的地方，不是不会填表，而是把“原因”写成了现象，把“措施”写成了口号。这样前面看起来每一列都填了，后面一到整改和复盘阶段，团队还是不知道该改什么、由谁改、改完怎么验证。权威资料对这件事的口径很一致，FMEA本质上是围绕失效模式、失效后果和失效原因做系统分析，并通过风险优先级或行动优先级把改进动作落下来。AIAG也明确把AIAG与VDA FMEA手册定义为当前汽车行业的重要参考，并采用结构分析、功能分析、失效分析、风险分析、优化和结果文件化的分步方法。